29 实践课-多轮对话优化与场景落地
多轮对话优化与场景落地
关联:索引
术语小抄(初学者版)
-
历史丢失(History Loss):系统没把“上一轮关键事实/状态/证据”带入当前轮,导致模型/规则无法承接。
-
指代错误(Coreference Error):把“这个/它/上一个指令”绑定到错误实体(错物品、错箱位、错动作),引发误操作风险。
-
上下文关联规则(Context Linking Rules):决定当前轮要带哪些历史、以什么结构带、优先级如何、什么时候追问澄清。
-
上下文污染(Context Pollution):把无关闲聊、无证据推测、错误信息喂给模型,导致输出漂移或“越记越乱”。
-
工业交互规范(Industrial Dialogue Spec):面向一线操作的输出约束:短句、指令明确、可执行、可追踪、可回退。
-
适配性验证(Fit Check):用真实/模拟产业对话样本验证功能能否“在目标场景稳定工作”,并形成可量化评分与改进建议。
-
先修:建议完成 28(多轮对话闭环与标注评估脚本)并能跑通本地示例。
-
环境口径:Python 3.10+;示例优先使用标准库;如要接入 LLM 进行摘要/结构化增强,可沿用 08/28 的依赖版本与密钥管理方式。
-
统一约束:长期记忆不写入敏感信息;输出必须带证据字段(至少
trace_id/parse_trace_id),并能用标注数据回归验证优化效果。
-
用户先说:“把苹果放到 A 箱。”再说:“它改放到 B 箱。”你们的系统为什么会把“它”当成香蕉/当成电池?
-
用户说:“按上一个指令再来一次。”系统明明有
task_state,为什么还是追问或重复错动作? -
完成一份“多轮对话问题诊断清单”并能对你们的项目日志做归类(历史丢失/指代错误/上下文污染/该追问未追问等)。
-
在现有标注数据基础上扩充 ≥20 条多轮样本,并能跑出“按类型统计”的指标(至少输出
by_type与fail_modes)。 -
落地一套可配置的“上下文关联规则”(窗口 + 状态 + 证据),能减少至少 1 类常见失败样例。
课程思政融入点(口径统一):
- 多轮对话优化的价值不在“说得像人”,而在“更少返工、更少误操作、更贴合产线节奏”。以地方苹果分拣为例:一线人员需要的是更快更稳的指令承接与纠错能力。技术必须贴合地方产业实际需求,才能真正服务地方经济发展。
1)历史丢失(系统没“带上关键历史”)
session_id丢失/混用,导致不同对话串台。- 短期窗口截断过小,把关键事实裁掉(例如箱位、上一步动作)。
- 只保存了原始对话文本,没有保存“结构化状态”(
last_item/last_bin/last_action)。 - 工具调用证据没带入上下文,模型只能靠猜(例如“分拣规则查询结果”未进入本轮输入)。
2)指代错误(系统“带了历史但绑错了”)
- 过度替换:把“这个苹果”替换成“苹果苹果”,或把新实体覆盖掉。
- 错实体绑定:把“它/这个”绑定到上上轮物品而非上一轮。
- 该追问未追问:关键槽位缺失仍继续执行控制类动作。
- 先看
session_id与task_state是否正确更新(状态是否可复现)。 - 再看“上下文关联规则”:本轮输入到底喂了哪些历史与证据(是否漏了关键字段/喂了无关内容)。
- 最后看“解析与生成”:是解析槽位错(
parse_trace_id)还是回复组织/执行错(trace_id)。
目标:把“感觉不对”变成“可记录、可统计、可回归”的问题单。
1)定义对话日志(JSONL,一行一条对话轮次)
{"session_id":"demo","turn_id":"t1","ts_ms":1710000000000,"user_text":"把苹果放到A箱","task_state_before":{},"assistant_text":"已理解:把苹果放到A箱(trace_id=demo1)","parse_trace_id":"p1","trace_id":"r1","slots":{"action":"put","item_name":"苹果","bin":"A"},"issue":null}
{"session_id":"demo","turn_id":"t2","ts_ms":1710000001000,"user_text":"上一个指令再来一次","task_state_before":{"last_item":"苹果","last_action":"put","last_bin":"A","last_raw_user":"把苹果放到A箱"},"assistant_text":"已理解:把苹果放到A箱(trace_id=demo2)","parse_trace_id":"p2","trace_id":"r2","slots":{"repeat_of":"把苹果放到A箱","action":"put","item_name":"苹果","bin":"A"},"issue":null}
{"session_id":"demo","turn_id":"t3","ts_ms":1710000002000,"user_text":"它改放到B箱","task_state_before":{"last_item":"苹果","last_action":"put","last_bin":"A","last_raw_user":"上一个指令再来一次"},"assistant_text":"需要澄清:你说的“它”指的是哪个物品?(trace_id=demo3)","parse_trace_id":"p3","trace_id":"r3","slots":{"need_clarification":true,"bin":"B","action":"put"},"issue":{"type":"COREF_ERROR","note":"task_state_before 已有 last_item,但指代消解仍触发澄清,说明“状态未被正确使用/规则未命中”"}}
{"session_id":"demo","turn_id":"t4","ts_ms":1710000003000,"user_text":"这个不要了,换成香蕉","task_state_before":{"last_item":"苹果","last_action":"put","last_bin":"A","last_raw_user":"把苹果放到A箱"},"assistant_text":"已理解:替换物品为香蕉,将沿用上一条动作/箱位(trace_id=demo4)","parse_trace_id":"p4","trace_id":"r4","slots":{"ref_item":"苹果","action":"replace","item_name":"香蕉"},"issue":null}
解释与自检要点:
- JSONL:便于追加与筛选;每条记录独立,失败时能快速定位到某一行。
task_state_before:用于复现实验条件;排查历史丢失时尤其关键。slots:把自然语言变成可执行参数,这是后续“按类型统计、回归验证”的基础。issue:本讲新增字段,用于把问题结构化归类(不要求每条都有)。
2)实现问题归类脚本 analyze_dialogue_issues.py
# analyze_dialogue_issues.py
# 目标:把多轮对话“哪里不好用”变成可统计的结构化问题类别,便于:
# - 课堂快速定位:历史丢失 vs 指代错误 vs 合理追问
# - 工程回归:用同一套分类规则对比“修复前/修复后”的问题分布
# - 写作业:输出 issue_counts 与典型 examples(可截图/可复盘)
import json
from typing import Any, Dict, List, Tuple
def _as_dict(x: Any) -> Dict[str, Any]:
# 容错:确保后续对 x.get(...) 的调用不会崩溃
# - 若 x 不是 dict,则当作空 dict(表示“没有状态/没有槽位”)
return x if isinstance(x, dict) else {}
def classify_issue(turn: Dict[str, Any]) -> Tuple[str, str]:
# 输入:一轮对话的结构化记录(来自 dialogue_turns.jsonl 的一行)
# 输出:(issue_type, note)
# - issue_type:用于统计聚合(例如 HISTORY_LOSS / COREF_ERROR)
# - note:用于展示说明(便于学生理解为什么被归类)
user_text = str(turn.get("user_text", "")).strip()
slots = _as_dict(turn.get("slots"))
state = _as_dict(turn.get("task_state_before"))
if not str(turn.get("session_id", "")).strip():
# session_id 是多轮对话的“绑定键”
# - 缺失会导致不同用户/不同任务串台,属于高优先级问题
return "SESSION_MISSING", "session_id 为空,可能导致多会话串台"
if "它" in user_text or "这个" in user_text or "上一个" in user_text:
# 只要出现典型指代词,就进入“指代/回放”类诊断分支
if slots.get("need_clarification") is True:
# need_clarification=True:系统选择“追问澄清”
# 追问不一定是错,但如果 task_state 里已经有足够信息仍追问,
# 说明:状态未被正确使用 / 未传入解析模块 / 规则未命中
if "上一个" in user_text and not str(state.get("last_raw_user", "")).strip():
# “上一个指令”需要 last_raw_user(上一轮原始用户指令)才能回放
return "HISTORY_LOSS", "缺 last_raw_user,无法回放上一个指令"
if ("它" in user_text or "这个" in user_text) and not str(state.get("last_item", "")).strip():
# “它/这个”需要 last_item(上一轮物品)才能绑定指代
return "HISTORY_LOSS", "缺 last_item,无法绑定指代"
if ("它" in user_text or "这个" in user_text) and str(state.get("last_item", "")).strip():
# state 已有 last_item 却仍追问:更像“指代规则没用上”
return "COREF_ERROR", "task_state 已有 last_item,但仍触发澄清:可能是指代规则未命中/状态未传入解析模块"
if "上一个" in user_text and str(state.get("last_raw_user", "")).strip():
# state 已有 last_raw_user 却仍追问:更像“回放规则没用上”
return "COREF_ERROR", "task_state 已有 last_raw_user,但仍触发澄清:可能是回放规则未命中/状态未传入解析模块"
# 其它追问:可能是合理行为(例如用户信息确实不足)
return "NEED_CLARIFY", "触发澄清追问(可能是合理行为)"
if ("它" in user_text or "这个" in user_text) and slots.get("ref_item"):
# ref_item:被指代的“旧实体”(例如“这个不要了”里的“这个”)
# item_name:当前轮最终要执行的实体(例如“换成香蕉”里的“香蕉”)
# action:本轮动作(put/query_rule/replace/cancel 等)
ref_item = str(slots.get("ref_item", "")).strip()
item_name = str(slots.get("item_name", "")).strip()
action = str(slots.get("action", "")).strip()
if ("换成" in user_text or action == "replace") and ref_item and item_name and item_name == ref_item:
# replace 场景里,新实体与旧实体不应相同
# 若相同,常见原因是“过度替换/新实体丢失”,属于指代错误
return "COREF_ERROR", "replace 场景新旧实体被覆盖为同一值,疑似“新实体丢失/过度替换”"
if action in ("put", "query_rule") and ref_item and item_name and item_name == ref_item:
# pronoun 场景里,item_name 继承 ref_item 是合理承接
# 例如:“把它放到B箱”应继承上一轮的物品名
return "OK", "pronoun 场景:item_name 继承 ref_item,属于正常指代承接"
if slots.get("action") in ("put", "replace") and not slots.get("item_name"):
# 控制类动作(put/replace)缺 item_name 风险较高:容易误操作
# 工业场景建议:追问澄清或拒绝执行(门禁)
return "SLOT_MISSING", "控制类动作缺 item_name,建议追问或拒绝执行"
# 默认:未发现明显问题(或该问题不在本脚本的最小覆盖范围)
return "OK", "未发现明显问题"
def main() -> None:
# 约定:dialogue_turns.jsonl 与脚本同目录
# - 一行一条 JSON(不要跨行),便于追加/定位/筛选
path = "./dialogue_turns.jsonl"
counts: Dict[str, int] = {}
samples: Dict[str, List[Dict[str, Any]]] = {}
with open(path, "r", encoding="utf-8") as f:
for line in f:
line = line.strip()
if not line:
continue
# 逐行解析:每行必须是一个完整 JSON 对象
turn = json.loads(line)
t, note = classify_issue(turn)
counts[t] = counts.get(t, 0) + 1
if t != "OK":
# 只收集非 OK 的样例,便于课堂展示与写“问题修复记录”
samples.setdefault(t, []).append(
{
"turn_id": turn.get("turn_id"),
"user_text": turn.get("user_text"),
"task_state_before": turn.get("task_state_before"),
"slots": turn.get("slots"),
"note": note,
}
)
# 统计输出:先按数量降序,便于定位“最常见的问题”
print("issue_counts:", dict(sorted(counts.items(), key=lambda x: (-x[1], x[0]))))
for t in sorted(samples.keys()):
print("----", t, "examples:")
for s in samples[t][:3]:
print(s)
if __name__ == "__main__":
# 运行方式:py -3 .\analyze_dialogue_issues.py
main()
逐段解释与自检要点:
classify_issue:只做“最小可用”的规则归类,不追求覆盖所有语义;核心是把问题变成可统计类别。HISTORY_LOSS与NEED_CLARIFY要区分:追问不一定是失败,但“该能承接却追问”通常意味着历史丢失或规则没带到。
3)运行自测(PowerShell)
py -3 .\analyze_dialogue_issues.py
解释与自检要点:
- 你应看到
issue_counts与若干examples。 - 如果提示找不到文件:检查是否与
dialogue_turns.jsonl在同一目录;或确认当前工作目录正确。
目标:用“扩充标注数据 + 调整规则”实现可量化提升,而不是靠感觉“越改越乱”。
1)扩充多轮标注数据(建议模板)
-
历史丢失类:模拟
task_state缺字段、短期窗口过短、上一步工具证据缺失。 -
指代错误类:包含“这个/它/刚才那个/上一个指令/再来一次”,并覆盖“指代 + 新实体”。
-
工业交互类:要求输出中必须包含可执行的结构化槽位或明确的澄清问题。
-
每条样本都要写清
task_state(复现条件)与expected.slots(评估目标)。 -
优先标注关键槽位:
action/item_name/ref_item/bin/need_clarification。
2)实现“上下文关联规则”配置 context_policy.py
# context_policy.py
# 目标:把“每轮到底带哪些上下文”变成可配置策略,而不是写死在业务代码里。
# 好处:
# - 可 A/B 测试:改 max_turns 或字段列表即可比较效果
# - 可回归:配合标注数据验证“策略调整是否减少失败样例”
# - 可审计:上下文输入可落盘复现,排障更快
from __future__ import annotations
from dataclasses import dataclass, field
from typing import Any, Dict, List, Optional
@dataclass(frozen=True)
class ContextPolicy:
# max_turns:短期对话窗口上限(只截取最近 N 轮)
# - 控制 token 成本与延迟
# - 避免历史无限增长导致“上下文污染”
max_turns: int = 10
# include_task_state_keys:从长期状态里挑“必须带入”的关键字段
# - 只带关键字段,不带整份长期记忆,避免污染与泄露
include_task_state_keys: List[str] = field(
default_factory=lambda: ["last_item", "last_bin", "last_action", "last_raw_user"]
)
# include_evidence_keys:工具证据/摘要字段(建议只放可验证的结果摘要)
# - 目的:减少模型“凭空编造”,并让输出可追溯
include_evidence_keys: List[str] = field(
default_factory=lambda: ["last_tool", "last_tool_ok", "last_tool_summary"]
)
def build_context_payload(
*,
user_text: str,
recent_turns: List[Dict[str, Any]],
task_state: Dict[str, Any],
policy: Optional[ContextPolicy] = None,
) -> Dict[str, Any]:
# policy=None 时使用默认策略,保证“最小可用且可运行”
p = policy or ContextPolicy()
# recent_turns:只保留最近 max_turns 轮,避免无限增长
turns = recent_turns[-int(p.max_turns) :] if recent_turns else []
# 从 task_state 中按白名单抽取字段,形成“上下文状态区”
state_payload: Dict[str, Any] = {}
for k in p.include_task_state_keys:
v = task_state.get(k)
if v not in (None, "", [], {}):
state_payload[k] = v
# 从 task_state 中按白名单抽取工具证据字段,形成“证据区”
evidence_payload: Dict[str, Any] = {}
for k in p.include_evidence_keys:
v = task_state.get(k)
if v not in (None, "", [], {}):
evidence_payload[k] = v
# 统一返回结构:便于落盘、复现、调试、对齐提示词/模型输入
return {
"user_text": user_text,
"recent_turns": turns,
"task_state": state_payload,
"evidence": evidence_payload,
}
逐段解释与自检要点:
ContextPolicy:把“带哪些上下文”的决策配置化,便于 A/B 测试与回归,不要把规则写死在代码里。include_task_state_keys:只挑“关键状态”进入上下文,减少污染;避免把所有长期记忆都喂给模型。evidence:把工具证据以摘要形式带入(例如“上一轮查询到苹果分拣规则是 A”),减少“模型凭空编”。
3)把策略接入对话入口(对齐 28 的 DialogueManager.handle 思路)
集成要点(示例为伪代码,工程里替换成你们的 Agent 调用即可):
handle(user_text):
1) load task_state + recent_turns
2) context_payload = build_context_payload(...)
3) 用 context_payload 做解析与回复生成(规则或 LLM)
4) 写入 short_term(user/assistant)
5) 回写 long_term:只写关键字段(last_* + last_tool_summary)
自检要点:
- 把“上下文”当成输入契约:每一轮都能打印/落盘
context_payload,才能复现“为什么它理解错了”。 - 当问题是“历史丢失”时,优先查
context_payload里有没有你以为带了但实际上没带的字段。
2)在 ContextPolicy.include_task_state_keys 里增加/删除 1 个字段,观察对某一类样本的影响。
提示:把 last_raw_user 去掉通常会让“上一个指令”类样本变差。
把“问题归类 + 上下文关联规则”接入你们的分拣智能体:
-
目标:让系统在“上一个指令/它/这个”类输入上减少误判,并在缺关键槽位时稳定追问。
-
步骤:增加日志字段(
task_state_before/context_payload/slots/issue)→ 扩充标注样本 → 跑回归指标 → 定向修复失败模式。 -
为什么“多轮能承接”还不等于“工业可用”?
参考答案要包含:回复冗长影响效率、指令不明确导致二次沟通、缺少证据字段难以排障、缺少拒绝/澄清机制有误操作风险。 -
输出一份“工业场景多轮对话交互规范”并在你们项目里落地一个统一回复模板(含
trace_id与下一步指令)。 -
用 AI 辅助分析失败样例并生成“上下文理解增强方案”(规则或代码补丁),并用标注数据回归验证至少 1 项指标提升或失败样例减少。
-
完成分拣/苹果分拣场景的适配性验证:提交 ≥3 组产业场景对话示例与适配性评分。
课程思政融入点(口径统一):
- 以地方苹果分拣系统为例:产业场景的核心是“效率、稳定、可交付”。技术选择与优化方向必须贴合地方产业实际,才能形成真正的生产力。做工程要有服务地方经济的意识与责任感。
1)简洁性:一句话说结论 + 一句话说下一步
- 好:先给结果,再给可执行下一步。
- 不好:长篇解释、输出过多内部推理、让一线人员读不完。
2)指令明确性:动作/对象/位置/约束必须齐
- 对控制类动作:必须明确
action + item + target_bin(缺字段就追问或拒绝)。 - 对查询类动作:必须明确
query_target + evidence_source(告诉用户依据来自哪里,例如“规则库/知识库/传感器”)。
3)可追踪:每轮必须有追踪字段
- 最少:
trace_id(对话链路)与parse_trace_id(解析链路)。 - 建议:输出里包含“本轮理解到的结构化槽位摘要”(不暴露敏感信息)。
4)可回退:错误风险场景必须可撤销/可更正
- 当用户出现“取消/撤回/改放”时,系统优先提供“确认 + 回退策略”,不要直接执行不确定操作。
目标:把回复格式固定住,减少“模型输出漂移”,并让一线操作更快更稳。
1)实现回复格式化函数 reply_format.py
# reply_format.py
# 目标:把工业场景的对话输出固定成统一结构,减少“模型输出漂移”,便于系统对接与回归验证。
# 设计原则:
# - summary:给人看的最短结论
# - next_step:下一步可执行指令/追问(减少来回沟通)
# - trace_id/parse_trace_id:证据字段(可追踪、可排障、可复验)
# - slots:给工程看的结构化信息(可直接用于工具调用/路由)
from __future__ import annotations
import json
from typing import Any, Dict, Optional
def format_industrial_reply(
*,
ok: bool,
trace_id: str,
parse_trace_id: str,
summary: str,
next_step: Optional[str] = None,
slots: Optional[Dict[str, Any]] = None,
warnings: Optional[list] = None,
) -> str:
# payload 是对外输出的“统一契约”
# - 使用 dict 组织,再 json.dumps,避免手拼字符串出错
payload: Dict[str, Any] = {
# ok:本轮处理是否成功(注意:并不等价于业务动作已执行)
"ok": bool(ok),
# trace_id:对话链路追踪(定位“执行/生成/路由”问题)
"trace_id": str(trace_id),
# parse_trace_id:解析链路追踪(定位“理解/槽位抽取”问题)
"parse_trace_id": str(parse_trace_id),
# summary:给用户看的最短结论(工业现场强调简洁)
"summary": str(summary).strip(),
# next_step:下一步指令或澄清问题(为空则输出空字符串)
"next_step": (str(next_step).strip() if next_step else ""),
# slots:结构化槽位,供系统端复用(非 dict 则回退为空 dict)
"slots": (slots if isinstance(slots, dict) else {}),
# warnings:非致命问题集合(保留证据但不阻断主流程)
"warnings": (warnings if isinstance(warnings, list) else []),
}
# ensure_ascii=False:保证中文可读;默认会输出 UTF-8 字符
return json.dumps(payload, ensure_ascii=False)
逐段解释与自检要点:
- 输出 JSON 字符串:便于前端/上位机直接解析展示;也便于写回日志做回归。
summary:给人看的最短结论。next_step:给人看的下一步指令或澄清问题,减少来回沟通成本。slots:给工程看的结构化信息(对齐你们工具调用契约),减少“只看自然语言”的不确定性。
2)示例输出(对一线人员友好)
{"ok":true,"trace_id":"r8f2a1c3","parse_trace_id":"p0a1b2c3","summary":"已理解:把苹果放到B箱","next_step":"如需更正,请说:改放到X箱 / 取消上一步","slots":{"action":"put","item_name":"苹果","bin":"B"},"warnings":[]}
自检要点:
- 这段输出可直接复制粘贴到 JSON 校验器中检查格式。
目标:让 AI 的输出变成可交付的工程改动,而不是“看起来很对”。
1)给 AI 的指令模板:生成诊断清单与改进建议
你是资深对话系统工程师。请基于以下信息输出一个“可落地”的多轮对话优化方案:
1) 当前系统的对话问题统计(issue_counts、fail_modes、by_type)
2) 代表性失败样例(bad_cases,含 task_state_before、input、expected_slots、pred_slots)
输出要求:
- 先给“问题诊断清单”(按严重程度排序:误操作风险 > 频率 > 修复成本)
- 再给“最小改动方案”(只能修改:上下文关联规则 / 指代消解规则 / 澄清策略)
- 每条改动都要说明:会影响哪些样本类型、如何用标注数据回归验证
- 不要引入新第三方依赖
说明与自检要点:
- 把“统计 + 失败样例”喂给 AI,AI 才能提出针对性的可落地改动。
- 明确约束“只能改哪些模块”,减少 AI 产出不可控大改。
2)给 AI 的指令模板:生成上下文理解增强代码(需可审计)
你是资深 Python 工程师。请在不引入第三方依赖的前提下,给出对以下函数的最小补丁:
- build_context_payload(...)
- resolve_sorting_references(...)
已知问题:
1) pronoun 类样本中,用户说“它改放到B箱”会触发不必要追问
2) replace 类样本中,“这个不要了,换成香蕉”偶发把新实体覆盖掉
输入:失败样例(含 task_state_before、input、expected_slots、pred_slots)
输出:
- 修改后的完整函数代码(可直接复制)
- 每处修改的理由
- 用 evaluate_coref.py 回归验证的预期变化(指标或失败样例减少)
说明与自检要点:
-
让 AI 输出“完整函数代码”而不是片段,便于你们直接替换并审计。
-
必须带“回归验证预期”,否则无法判断改动是否有效。
-
正确性(0–2):槽位解析是否正确、是否避免误操作。
-
交互效率(0–2):回复是否简洁、是否减少重复说明。
-
可追踪性(0–2):是否输出
trace_id/parse_trace_id与关键槽位摘要。 -
容错与回退(0–2):缺信息是否追问、错误是否可撤销/更正。
-
场景贴合(0–2):是否符合苹果分拣现场表达与流程(例如“等级/重量/果径/瑕疵”表达方式)。
总分 10 分,建议 ≥8 分视为“可落地候选”,<8 分需给出改进项与下一轮验证计划。
2)苹果分拣对话样例(参考,学生可替换为本地产业口径)
样例 A(指代承接):
- 用户:把这箱苹果按“中果”标准分到 B 线
- 用户:它再按“轻微碰伤”单独挑出来
样例 B(纠错回退):
- 用户:把上一条再来一次
- 用户:不对,改成按“大果”标准
样例 C(澄清追问):
- 用户:把它放到 A 区
- 系统:追问“它”指代对象,并提示可选项(上一步物品/批次/箱号)
自检要点:
-
每组样例至少包含 3 轮对话(体现“多轮承接/纠错/澄清”之一)。
-
输出里必须能看到结构化槽位与追踪字段,否则无法写“适配性验证报告”。
-
演示:使用 AI 分析对话问题、生成优化方案的过程(输出必须可审计、可回归)。
-
组织分组:每组选择“分拣/苹果分拣/自选题场景”之一,完成 3 组对话样例与评分,并提出 1 条场景化调整建议。
-
测试多轮对话功能,记录上下文理解不足的问题:至少 6 条问题记录,包含
user_text/task_state_before/slots/问题类型。 -
利用标注的多轮对话数据扩充训练集(标注集):新增 ≥20 条样本,并跑出按类型统计指标截图(至少
by_type)。 -
按照工业场景规范调整对话回复格式:项目输出中可见统一格式(建议 JSON)与
trace_id/parse_trace_id。 -
验证功能在自选题场景中的适配性:提交 3 组对话样例 + 适配性评分(总分 10)+ 1 条改进建议。
大模型任务(可直接复制的指令模板)
- 生成多轮对话问题诊断清单与优化方案:输入统计与失败样例,输出最小改动方案与回归验证点。
- 针对对话问题生成上下文理解增强代码:限定只改上下文关联规则/指代消解/澄清策略,输出完整函数与理由。
- 提供工业场景多轮对话交互规范参考:给出“短句模板 + 追问模板 + 回退模板”,并说明适用条件。
- 辅助验证功能适配性:基于 3 组产业对话样例给出评分与场景化调整建议(不要引入新依赖)。
作业:布置
1)提交优化后的多轮对话代码、问题修复记录。
要求:至少包含 1 个“修复前失败样例”与“修复后通过样例”,并说明根因与改动点。
2)提交场景适配性验证报告(含 3 组产业场景对话示例、适配性评分),300 字左右。
要求:每组示例至少 3 轮对话;评分需包含 5 个维度(每项 0–2)与总分,并写 1 条改进建议。
3)提交标注数据扩充与优化的过程记录,说明优化前后的效果对比。
要求:提供新增样本数量、by_type 指标截图(或文本输出),并描述至少 1 个失败模式如何被修复(或如何缩小影响范围)。
Markdown 与代码自检清单(提交前必做)
- 标题层级连续(
#→##→###→####),无跳级。 - 所有代码块成对闭合,且语言标签正确(
jsonl/python/powershell/text/json)。 - PowerShell 命令可在 Windows 环境直接运行(
py -3存在时优先使用)。 - Python 示例仅依赖标准库,且可独立运行(文件名与 import 对应)。